Some ioctls seem to be specific to certain CDROM drives. That is, they are introduced to service some capabilities of certain drives. In fact, there are 6 different ioctls for reading data, either in some particular kind of format, or audio data. Not many drives support reading audio tracks as data, I believe this is because of protection of copyrights of artists. Moreover, I think that if audio-tracks are supported, it should be done through the VFS and not via ioctls. A problem here could be the fact that audio-frames are 2352 bytes long, so either the audio-file-system should ask for 75264 bytes at once (the least common multiple of 512 and 2352), or the drivers should bend their backs to cope with this incoherence (to which I would be opposed). Once this question is resolved, this code should be standardized in cdrom.c.
Because there are so many ioctls that seem to be introduced to satisfy certain drivers,3 any `non-standard' ioctls are routed through the call devioctl (). In principle, `private' ioctls should be numbered after the device's major number, and not the general CDROM ioctl number, 0x53. Currently the non-supported ioctls are: CDROMREADMODE1, CDROMREADMODE2, CDROMREADAUDIO, CDROMREADRAW, CDROMREADCOOKED, CDROMSEEK, CDROMPLAYBLK and CDROMREADALL.